2.4. Controlling Database Activation
In large environments you may
want to limit which servers can host an active database in the event of
a failure so that a database is not brought online in a secondary
datacenter if you are performing maintenance on a server or the
database is a lagged copy. A database
activation policy can be set on the Mailbox server, or only the
database copy can be configured to not activate. When setting this on
the Mailbox server using Set-MailboxServer ServerName –DatabaseCopyAutoActivationPolicy, the following three policies are available:
Blocked No database can be automatically activated.
IntrasiteOnly This prevents database failovers from copies that are not in the same Active Directory site.
Unrestricted This allows any server in the DAG to be for database activation. This is the default configuration.
These policies only affect
how Active Manager calculates where to activate database copies. An
administrator can manually mount the database on a server that has the
activation policy set to Blocked. The server auto activation policy is
usually used during periods of maintenance when you do not want a
database copy to be automatically activated on a specific server.
The second way to control database activation is to suspend database activation on a specific copy of the database. This can be done by running Suspend-MailboxDatabaseCopy <Database Name>\<Server Name> -ActivationOnly, as shown in Figure 7.
Suspending activation for a specific database copy should be done on
copies that you do not want to be activated automatically, such as
lagged database copies.
Unlike setting an
activation policy on the Mailbox server, suspending activation on a
database copy cannot be mounted directly by an administrator, as shown
in Figure 8.
However, this block can be reset in two ways: when the database copy is
reseeded or if replication is suspended and then resumed.
2.5. Transport Dumpster
In case failure occurs and some transaction logs are not replicated to the passive copy, the transport
dumpster is used to redeliver any recently delivered e-mail. If a
database failure occurs, a request is made to the Hub Transport servers
to redeliver any lost e-mail messages.
The transport dumpster only retains e-mail that has already been delivered. The local
submission queue withholds any pending outgoing e-mail. After the
transaction logs containing the e-mail message are replicated to and
inspected by each DAG member with a copy of the database, the Hub
Transport server purges the message from the dumpster.
The transport dumpster is enabled by default. Transport dumpster can be configured by using the Get-TransportConfig cmdlet using the following two properties:
MaxDumpsterSizePerDatabase This setting defines the maximum size of the transport
dumpster queue per database and is set globally for the entire Exchange
organization. The recommended size is 1.5 times the maximum message
size that can be sent. For example, if the maximum size for messages is
20 MB, this parameter should be set to 30 MB.
MaxDumpsterTime This is the time for which the transport
dumpster retains a message if the message is not purged for exceeding
the maximum dumpster size. The default is set to seven days.
